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NATIONAL FOREWORD 

This Indian Standard ( Part 1 ) which is identical with ISO 15022-1 : 1999 'Securities — Scheme for 
messages ( Data Field Dictionary ) — Part 1 : Data field and message design rules and guidelines' 
issued by the International Organization for Standardization ( ISO ) was adopted by the Bureau of 
Indian Standards on the recommendations of the Banking and Financial Services Sectional Committee 
and approval of the Management and Systems Division Council. 

The text of the International Standard has been approved as suitable for publication as an Indian 
Standard without deviations. Certain conventions are, however, not identical to those used in Indian 
Standards. Attention is particularly drawn to the following: 

a) Wherever the words 'International Standard' appear referring to this standard, they should be 
read as 'Indian Standard'. 

b) Comma ( , ) has been used as a decimal marker while in Indian Standards, the current practice 
is to use a point ( . ) as the decimal marker. 

In the adopted standard, references appear to certain International Slandards for which Indian Standard 
also exist. The corresponding Indian Standards which are to be substituted in their places are listed 
below along with their degree of equivalence for the editions indicated: 



International Standard 

ISO 1 5022-2 : 1 999 Securities — 
Scheme for messages ( Data Field 
Dictionary ) — Part 2 : Maintenance 
of the data field dictionary and 
catalogue of messages 

ISO/IEC 646 : 1991 Information 
technology — ISO 7-bit coded 
character set for information 
interchange 



Corresponding Indian Standard 

IS 15587 (Part 2) : 2005 
Securities — Scheme for messages 
( Data Field Dictionary ): Part 2 
Maintenrance of the data field 
dictionary and catalogue of messages 

IS 10315 1997 Information 

technology — ISO 7-bit coded 

character set for information 
interchange 



Degree of Equivalence 
Identical 
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The technical committee responsible for the preparation of this standard has reviewed the provisions of 
the following International Standards and has decided that they are acceptable for use in conjunction 
with this standard: 



International Standard 
ISO/IEC 8859-1 



Title 

Information technology — 8-bit single-byte coded graphic character sets — 
Part 1 : Latin alphabet No. 1 



ISO 9735 (all parts ) Electronic data interchange for administration, commerce and transport 
( EDIFACT ) — Application level syntax rules 



ISO/IEC 10646-1 



Information technology — Universal Multiple-Octet Coded Character Set 
( DCS ) — Part 1 : Architecture and basic multilingual plane 



Technical Corrigendum 1 of the International Standard has been given at the end of this publication. 
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Introduction 

This part of ISO 15022 replaces ISO/TR 7775, Securities — Scheme for message types and ISO 11521, Securities — 
Scheme for interdepository message types. In the nnid-1990s, it was felt strongly that the International Standards for 
communication between securities industry participants required an urgent review aiming at (1) reducing the time 
taken to deliver new message types to the market place and (2) improving "straight through processing" capabilities. 

ISO 15022 sets the principles necessary to provide the different communities of users with the tools to design 
message types to support their specific information flows. These tools consist of: 

— a set of syntax and message design rules; 

— a dictionary of data fields; and 

— a catalogue for present and future messages built by the industry with the above-mentioned fields and rules. 

To address the evolving needs of the industry as they arise, the Data Field Dictionary and the Catalogue of 
Messages have been kept outside the standard. They are made available by a Registration Authority which updates 
them as necessary upon the request of industry participants. 

To protect investments already made by the industry, the syntax proposed in this part of ISO 15022, referred to as 
the "Enhanced ISO 7775 syntax", is based on the syntax used for the previous ISO 7775 and ISO 11521. However, 
to ensure the promotion, awareness and knowledge of the Electronic Data Interchange For Administration, 
Commerce and Transport (EDIFACT), a standard developed by the United Nations, adopted by ISO in 1988 as 
ISO 9735, and recommended as the International Standard for Electronic data interchange, ISO 15022 also 
supports the EDIFACT syntax. To recognize that a number of countries are currently or may in the future migrate to 
EDIFACT, the Registration Authority shall register EDIFACT fields and messages for use by securities industry 
participants. The ISO 15022 Data Field Dictionary shows how to format each data element required in securities 
messages in the €nhanced ISO 7775 syntax and in the EDIFACT syntax. Similariy, the Catalogue of Messages 
shows messages structured under both the Enhanced ISO 7775 and the EDIFACT message design ailes and 
syntax. 

ISO 15022 contains: 

— the Enhanced ISO 7775 syntax and message design rules; 

— the organization of the Data Field Dictionary and the Catalogue of Messages; 

— the service levels and procedures for the Registration Authority, including its supervision by ISO. 

The EDIFACT syntax referred to in this document is described in ISO 9735. 

It is expected that this new flexible framework will allow industry groups to build messages in an international 
language and to migrate to EDIFACT if desired, at the speed which matches the urgency of their needs. If none of 
the messages recorded in the Catalogue of Messages addresses their requirements, they will be able to agree on 
the use of a new one and to design it from the approved fields in the Enhanced ISO 7775 and/or EDIFACT syntax. 
The Registration Authority will create extra fields as necessary and record the new message types and versions in 
the Catalogue of Messages to avoid the duplication of effort by other groups who have similar needs. The 
Registration Authority will ensure that the new fields and the new messages are available in both the Enhanced 
ISO 7775 and the EDIFACT formats, as required. 

Straight through processing is expected to be enhanced because each community of users will be able to explicitly 
define its own business requirements and convert them into market specific message type versions. The approach 
differs from the generic intemational messages defined so far by ISO, which did not explicitly identify market 
specifics and therefore rendered the communication intertaces dependent on additional rules to be agreed 
bilaterally between senders and receivers. 
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Although the new framework permits multiple versions of the same message type, it is expected that market forces 
will naturally limit their creation to what is actually required until further convergence of market practices makes it 
possible to develop true international message standards for straight through processing. Similarly, it is expected 
that market forces will naturally organize the migration to EDIFACT at an appropriate pace. The dual structure of the 
Data Field Dictionary and Catalogue of Messages will facilitate the migration and the development of any required 
conversion mechanisms. 

NOTE ISO 1 5022 has been designed to incorporate and be upwards compatible with the previous securities message 
standards ISO 7775 and ISO 11521, as updated in ISO/TR 7775 . As a result, the initial Data Field Dictionary and Catalogue of 
Messages accommodate ISO/TR 7775 data fields and messages. However, some of the previous fields and messages are not 
fully compliant with the Enhanced ISO 7775 syntax, and none are compliant with EDIFACT. In addition, the initial Data Field 
Dictionary incorporates the Industry Standardization for Institutional Trade Communications (ISITC) DSTU 1/1995 and the 
Securities Standards Advisory Board (SSAB) data dictionaries. 

A list of standards related to this part of ISO 15022 is given in the bibliography. 
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Indian Standard 

SECURITIES — SCHEME FOR MESSAGES 
( DATA FIELD DICTIONARY ) 

PART 1 DATA FIELD AND MESSAGE DESIGN RULES AND GUIDELINES 

1 Scope 

This part of ISO 15022 consists of: 

— the description of the Enhanced ISO 7775 syntax and message design rules; 

— the contents and organization of the dictionary of Enhanced ISO 7775 and EDIFACT fields for securities 
messages; and 

— the contents and organization of the catalogue of- securities messages built in the Enhanced ISO 7775 and 
EDIFACT syntaxes. 

It refers to the EDIFACT syntax when necessary to ensure an easy cross-reference between Enhanced ISO 7775 
concepts and EDIFACT concepts. The EDIFACT syntax is not described in this part of ISO 15022; it is defined in 
ISO 9735 which is incorporated by reference. 

This part of ISO 15022 is used for electronic data interchange between securities industry participants, 
independently of the communication network. Network dependent rules, for example, on how to specify where and 
when the message is to be sent, message acknowledgement and message protection are outside the scope of this 
part of ISO 15022. 

The maintenance of this part of ISO 15022 is described in part 2 of ISO 15022. 

2 Normative references 

The following normative documents contain provisions which, through reference in this text, constitute provisions of 
this part of ISO 15022. For dated references, subsequent amendments to, or revisions of, any of these publications 
do not apply. However, parlies to agreements based on this part of ISO 15022 are encouraged to investigate the 
possibility of applying the most recent editions of the normative documents indicated below. For undated 
references, the latest edition of the normative document referred to applies. Members of ISO and lEC maintain 
registers of currently valid International Standards. 

ISO/I EC 646, Information technology — ISO 7-bit coded character set for information interchange. 

ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet 
No. 1. 

ISO 9735 (all parts). Electronic data interchange for administration, commerce and transport (EDIFACT) — 
Application level syntax rules. 

ISO/IEC 10646-1, Infonvation technology — Universal Multiple-Octet Coded Character Set (UCS) — Parti: 
Architecture and Basic Multilingual Plane. 

Reference is also made to ISO/TR 7775, which refers to Technical Report (type 2) 7775. This document contains all 
message types included in ISO 7775 and ISO 11521, as updated and complemented by the ISO 7775 Maintenance 
Agency until September 1994. 
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3 Terms and definitions 

For the purposes of this part of ISO 15022, the following terms and definitions apply. 

3.1 

block of data fields 

predefined and identified set of functionally related data fields related to a business concept 

NOTE A block of data fields is identified by a start of block and an end of block data field which both mention the block 
name, which qualifies the specific meaning of the block. The block of data fields may be repeating. A block of data fields may 
also include other, nested, blocks of data fields. 

3.2 

community of users 

financial institutions sharing the same market practice and using the same message standards 

3.3 

component data element 

simple data element which is a subordinate portion of a composite data element identified by its position within the 
composite data element 

3.4 

composite data element 

data element containing two or more component data elements 

3.5 

data element 

unit of data for which the identification, description and value representation have been specified 

NOTE A data element in certain contexts is considered indivisible. 

3.6 

data element tag 

(EDIFACT only) unique identifier for a data element in an EDIFACT data elements directory (see field tag) 

3.7 
data field 

data field consists of a field tag followed by a data item 

NOTE It is used to convey a simple data element or a composite data element which represents a unit of meaningful 
information. 

3.8 
data item 

expression of a single data element or a composite data element represented in a specific format and identified by 
the preceding field tag 

3.9 

data source issuer code 

string of characters used to identify the institution or market organization owning the data source scheme 

3.10 

data source issuer sub-code 

identification of the specific data source scheme for the data source issuer 

3.11 

data source scheme 

data source scheme consists of two sub-fields, the data source issuer code and the data source issuer sub-code, 
which are used in the data field tag to identify a proprietary scheme for the data item 
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3.12 

discrete data field 

data field which expresses a specific single business data item 

NOTE The field tag of a discrete data field does not need a qualifier to further define the business meaning of the data 
item. 

3.13 
field tag 

unique string of characters identifying the meaning, format, and value representation of the following data item (see 
data element tag) 

NOTE A field tag is made up of a field type optionally followed by a qualifier and a data source scheme. 

3.14 
field type 

unique string of characters which starts the field tag and identifies the format and value representation of the data 

item 

NOTE It also identifies either the meaning of the following data item (see discrete data field) or the class of the following 
data item (see generic data field). 

3.15 

generic data field 

data field used to express the data of a family or class of data items of the same nature, e.g. dates, amounts 

NOTE The field tag of a generic data field x:ontains a qualifier to specify the precise meaning of the following data item. 

3.16 

group of segments 

(EDIFACT only) identified, usually repeatable, grouping of segments 

3.17 
message 

series of data fields and/or blocks of data fields communicated from one party to another to convey meaningful 
business information 

NOTE In EDIFACT, a set of segments in the order specified in an EDIFACT message directory starting with the message 
header and ending with the message trailer. 

3.18 
message code 

unique string of characters identifying the message type 

3.19 

message descriptor 

string of characters which specifies the scope of the message and the fields that may be used 

NOTE A message descriptor is made up of a message code optionally followed by a version number and a message 
version sub-format. 

3.20 
message type 

identified and structured set of data items or data elements used to convey information related to a specific 
business scope 

3.21 

message version issuer code 

string of characters used to identify the institution or market segment owning the message version sub-format 
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3.22 

message version issuer sub-code 

identification of the specific message version sub-format for the message version issuer 

3.23 

message version sub-format 

message version sub-format consists of two sub-fields, the message version issuer code and the message version 
issuer sub-code, which are used in the message descriptor to identify a proprietary sub-format 

3.24 

nested segment 

(EDIFACT only) segment which directly relates to another segment in an identified and structured group of 
segments covering the requirements for a speqific message type 

3.25 

qualified data element 

data element whose precise meaning is conveyed by an associated qualifier 

3.26 

qualified segment 

(EDIFACT only) segment whose precise meaning is conveyed by an associated qualifier 

3.27 
qualifier 

data element whose value is expressed as a code that gives specific meaning to the function of another data 
element, data item, or segment 

3.28 

repeating segment 

(EDIFACT only) segment which mayl-epeat in a message as specified in the relevant message type specification 

3.29 
segment 

(EDIFACT only) predefined and identified set of functionally related data element values 

NOTE A segment starts with a segment tag and ends with a segment temninator. 

3.30 
segment tag 

(EDIFACT only) simple data element uniquely identifying a segment 

3.31 
separator 

character(s) used for the syntactical separation of data 

3.32 
sequence 

predefined set of data fields for documentation purposes only 

3.33 

simple data element 

data element containir)g a single value 

3.34 
sub-field 

subdivision or subordinate portion of a composite data element or of a field tag or of a message descriptor 

3.35 

version number 

allows different versions of the message type to be supported concurrently 
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4 Enhanced ISO 7775 Syntax and lexical format 

4.1 Basic principles 

Messages that are designed to comply with the Enhanced ISO 7775 standard and are part of the Catalogue of 
Messages, adhere to the following basic principles. 

— Messages must be system and network independent. 

— The scope of the message should not be dependent on the sender and/or receiver of the message. 

— A field tag should uniquely identify the following data item, independently of the message type or the position of 
the data field in a message. 

4.2 Character sets and lexical format 

This part of ISO 15022 accommodates data fields that comply with the following character sets. 

— ISO/IEC 8859-1 (Latin 1); 

ISO/IEC 8859-1 consists of 191 graphic characters and supports all the characters used in Danish, Dutch, 
English, Faroese, Finnish, French, German, Icelandic, Irish, Italian, Nonwegian, Portuguese, Spanish and 
Swedish. 

— ISO/IEC 1 0646-1 [Universal Multiple-Octet Coded Character Set (UCS)] 
This supports most non-Latin based languages; 

— Binary. 

4.2.1 Specifying lexical format 

The format of a field and its constituents is documented in the following way. 

Length restrictions nn minimum 1 character and maximum nn characters 

nnl fixed number of characters 

nn-nn range of characters 

nn*nn maximum number of lines x maximum number of characters per line 



Type of characters 



n digits 

d digits with a decimal comma 

s + or - sign (if optional, no sign implies a positive value) 

h upper case hexadecimals 

a upper case letters 

c upper case alphanumeric characters 

e blank space 

y upper case ISO 9735 characters (UNOA - Level A character set) 

z ISO/IEC 8859-1 (Latin 1) characters 

u ISO/IEC 1 0646-1 [Universal Multiple-Octet Coded Character Set (USC)] 

b binary 

7" character as-is, or 

"text" text as-is 
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Many of the data items in the Data Field Dictionary can accept lower case letters and other characters as well as 
upper case alphanumeric characters. They are of a data type z, i.e. they may consist of ISO/IEC 8859-1 (Latin 1) 
characters, which is the same as EDIFACT code list UNOC. Some networks do not support all these characters. 
Acceptable subsets of Latin 1 include: 

— ISO/IEC 646 With US national option. This is a 7-bit character set. 

The printable codes from 32 to 127 are identical with Latin 1 . 

— ISO 9735 EDIFACT code list UNOA - Level A character set (existing code 'y')- This is also the International 

Telex Character Set. 

— ISO 9735 EDIFACT code list UNOB - Level B character set. Upper and lower case letters. 

— S. W. I. F.T. character set. 

— Windows code page 1252 - Windows Latin 1 (ANSI) is in fact a superset of ISO/IEC 8859-1. 

4.2.2 Separators 

In addition to the character set used for defining data fields, control characters are required to syntactically 
separate: 

— data fields within a message (field separator); 

— field tag from data item (tag separator); 

— sub-fields within a data item, field tag or message descriptor (sub-field separator). 

Similarly, if it is required to include a control character within the text, it must be preceded by a release character to 
signify that it should be regarded as text. The release character itself should also be preceded by another release 
character if it is to be treated as text. 

The defined separators and release character are: 

— Field separator CRLF (carriage return-line feed) 

— Tag separator ":" (colon) (when not followed immediately by another ":"), or the second "/" after "::" 

— Sub-field separator 7", or "::" in a field tag 

— Release character "?" 



In addition, the end of a message is marked by a message delimiter. The format of a message delimiter is CRLF "-" 
(carriage return-line feed-minus sign). 

For an example see 4.3.2.1 . 

4.2.3 Notation used 

The following notation is used to describe the use of sub-fields, data fields, sequences of data fields or blocks of 
data fields. It is also used to describe the structure and use or fomnat of data fields and messages. 

The name of an item or a collection of items is often shown in "<....>" (the < and > characters do not form part of the 
message). 

If a character or sub-field is optional within a field, it is shown in square brackets "[...]". (The [ and ] characters do 
not form part of the message). 

Alternative items, i.e. one item to be used out of a series of items, are shown by separating them by an or sign "I". 
(The I character does not form part of the message.) 
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The following examples illustrate these points: 

EXAMPLE 1 2!z[1n] 

means a field which is either 2 acceptable Latin 1 characters long or 2 characters followed by a digit. 

EXAMPLE 2 3!c[T3!c[T8z]] 

means that theiormat can consist of three parts (sub-fields) which are separated by T characters, and it 
may consist of: 

sub-field 1 only 3!c 

sub-fields 1 &2 3lcT3!c 

or sub-fields 1,2 &3 3!cT3!cT8z 

NOTE In this example sub-field 3 may consist of any acceptable Latin 1 characters whereas sub-fields 1 and 2 can only 
consist of upper case alphanumeric characters. 

EXAMPLE 3 <A>I<B> 

EXAMPLE 4 <A>[<B>[<C>I<D>]] 

means either sequence A; sequence A,B; sequence A,B,C or sequence A,B,D. 

4.2.4 Defining numbers 

Numbers are frequently specified as format d. This format requires a decimal separator (i.e. a comma) to be always 
specified, with at least one digit before the comma. Leading and trailing zeroes are acceptable. Valid formats 

include: 

123, 12,3 0,123 123456, 123,0 

00123, 

The following are invalid formats: 

123 12.3 .123 .123 

123 456, 123.456, 123,456, 

4.3 Message structure and design rules 

This clause describes the various components of a message, and how they may be combined together. 
Each message consists of: 

— a message descriptor; 

— a number of data fields and/or blocks of data fields; 

— a message delimiter. 

The message header, which contains the message descriptor, and the message trailer, which contains the 
message delimiter, are considered to be system, network, or transmission medium-dependent and as a result are 
not part of this part of ISO 15022. However, the message descriptor and delimiter are considered to be part of this 
part of ISO 15022. 

A message may be constructed with its data fields and blocks of data fields in any order. This will not change the 
meaning of the message. 

4.3.1 Message descriptor 

The data content of each message must be preceded by a message descriptor. The descriptor identifies the scope 
of the message, the fields that may be specified and the conditions for their use. 

The message descriptor information must be included in the header. It consists of up to three sub-fields: a message 
code, an optional version number and an optional message version sub-format. 
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It is recommended to use the sequence: 

<message code> [<sub-field separator> <version number>[ <sub-field separator> <message version issuer 
code>[<message version issuer sub-code>]]] 

in the fonnat: 

3!c [T3!c[T4!c[4c]]] 

The message code (3!c) refers to a message type which defines the scope of the message, e.g. an order to buy. 

The version number (T3!c) allows different versions of the message type to be supported concurrently. It defines 
the data fields that may be used in the specific message type. If no version number is specified in the message 
descriptor, it is deemed to be message type version "000". It should be noted that there may not necessarily be an 
overall generic message type and version, which encompasses all the other current versions. 

The optional message version sub-format (T4!c[4c]) allows one to create proprietary sub-formats to refine a 
message type version by, for example, indicating that additional constraints or general usage guidelines apply, e.g. 
521/005/ISIT1997 could indicate that the following message is version five of message type 521, which is used in 
compliance with the requirements defined by ISITC in 1997. It should be noted that a sub-format is a user defined 
variation of a message type version and must be fully compatible with this message type version. 

4.3.1 .1 Message version sub-formats 

The Registration Authority (RA) will maintain a list of unique four-character message version issuer codes. When 
possible, they will consist of the first four characters of the BIG of the registering financial institution. If no BIG is 
available, the message version issuer code will be created by the RA. 

Once a message version issuer code has been registered, the message version issuer may then create its own set 
of message version sub-formats identified by its issuer code optionally followed by a unique four-character message 
version issuer sub-code of its choice. The RA will check the compliance of the message version sub-format with the 
related message version. Message version sub-formats are available for use by any user. 

4.3.1.2 Version number 

All new messages are given version numbers. By default, all existing messages (i.e. ISO/TR 7775 messages) 
are attributed version number "000". 

As stated above, message type alone (e.g. MT 521) identifies a message scope, but not a message format. Hence 
MT521 just means 'receive against payment', arid MT521/000 means the ISO/TR 7775 format of MT521. 

The version number is used in two ways: 

— for a new release of an existing version which will be phased out after a transitional conversion period, e.g. 
users of MT 521/067 decide to adopt a new fomnat for receive against payment, which will be called 521/089; 

— to identify the message formats used by different communities of users for the same scope, e.g. MT52 1/008 is 
the current version used by European Gustodians, 521/004 is the version used by International Gentral 
Securities Depositories (IGSDs), 521/154 is the current version of GREST,... 

Versions are described in the Gatalogue of Messages. They are not proprietary: anybody can use them, e.g. using 
the above example, DTG can start using 521/154 without asking GREST. 

One community of users cannot define several current versions of the same message type (except in the case of 
transition to a new release, as explained above). If a community wants to further identify the variations of the 
message fomnat in various specific situations, these "sub-formats" may be identified in the third sub-field of the 
message descriptor (i.e. the message version sub-format). Message version sub-formats are listed but not 
described in the Gatalogue of Messages. To ensure the uniqueness of a sub-format's identification, the message 
version issuer code must be registered with the Registration Authority. 
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e.g.: 

— 521/007/ISIT0001 is the sub-format of 521/007 registered by ISITC for a receive against payment instruction; 

— 521/023/DAKV is the sub-format of 521/023 registered by Deutsche Borse Clearing for a receive against 
payment instruction; 

— 521/004/CEDE0041 is the sub-format registered by Cede! Banl< for a receive against payment instruction 
between two Cedel members; 

— 521/004/CEDE0061 is the sub-format registered by Cedel Bank for a receive against payment instruction 
between a Cede! member and SICOVAM. 

NOTE All sub-formats of a message version must be fully compatible with the master version format, while the versions of 
a message type are normally not fully compatible with each other. 

4.3.2 Data field 

A data field consists of a field tag, followed by a tag separator and the data item. 

<field tag> <tag separator> <data item> 

A data field will normally only refer to one data element or possibly several related data elements whenlhey need to 
be combined to represent a meaningful unit of information, e.g. the settlement day + month + year need to be 
combined to form a meaningful settlement date data field; similarly, the settlement amount is the combination of the 
currency and the amount of money, because the amount of money alone does not mean anything. On the other 
hand settlement date and settlement amount are each meaningful units, which may need to be used separately and 
are thus in separate data fields. 

A data field may normally only occur once in a message if not in a block. 

For new data fields, the field tag will uniquely define the format, possible values and meaning of the following data 

item. 

Both the field tag and the data item may be divided into sub-fields. 

4.3.2.1 Field tag and tag separator 

The field tag uniquely identifies the business function and format of the following data item. It may contain one, two 
or three sub-fields depending on the type of data field. 

— Discrete data field 

The field tag consists of a single field type. 

<f ield typextag separator>, in the format: 
":"2!c[1c] ":" 

— Generic data field 

The field tag consists of two or three sub-fields: a field type, a qualifier, and in certain circumstances a data source 
scheme. 

<field typexsub-field separatorxqualifierxsub-field separator>[<data source issuer code>[<data 
source issuer sub-code>]]<tag separator>, in the format: 

":"2!c[1c] "::" 4!c T [4lc[4c]] "/" 

The field type (":"2!c[1c]) identifies either a specific field (discrete data field) or a class of fields (generic data field). It 
accommodates the existing ISO/TR 7775 field tags. A typical generic field type would signify a Date or a Party. 
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The qualifier (4!c) is a four-character code word. Typical qualifiers for the Date generic data field would identify 
different types of dates such as Trade, Settlement or Coupon dates. 

The Registration Authority will maintain a list of unique data source schemes. The data source scheme (4lc[4c]) 
may be only used for certain generic data fields (see Data Field Dictionary), it qualifies the following data item. 

EXAMPLE 1 The Start of Block discrete data field has a field type:16R, which can be used as follows: 

:16R:BL0CKNAME1 for the beginning of a blocl< called BL0CKNAME1. 

EXAMPLE 2 The Date/Time generic data field has a field type:98a, which can be used as follows: 

:98A::TRAD//1 9980302 for a trade date of 2 March 1998 

:98A::SETT//1 9980305 for a settlement date of 5 March 1998 

EXAMPLE 3 The Party generic data field has a field type:95a. Format option P specifies the BIC code of the party, 

whereas option R allows a proprietary code (i.e. issuer specific) to be specified as follows: 

:95P::BUYR//CITIGB2L for the buyer of securities being Citibank in London. 

:95R::BUYR/XISM/1 2345678 for the buyer of securities being identified by the 

proprietary code 12345678 allocated by ISMA. 

4.3.2.2 Data field status 

A data field within a message may have one of the following status in the Catalogue of Messages: 

— M mandatory; 

— C conditional: i.e. may or may not be required, or not allowed, depending on the circumstances as 

defined in the Catalogue of Messages; 

— O optional: the data field should be present when the underlying information exists and is known to the 

sender. However, the message is meaningful without the data field. 

4.3.2.3 Data item sub-field 

The data item within a field may be divided into various sub-fields. 

All sub-fields are separated by sub-field separators unless the sub-field consists of a currency and an amount, e.g. 

USD 123,45 
JPY10015. 

A data item sub-field may be either a 'code word', a 'structured value' or 'unstructured text'. 

The format of a code word is four upper case alphanumeric characters (i.e. 4!c). 

Examples of structured values include dates, integers and amounts of money. Structured values often have 
restrictions on the maximum and minimum values and the number of acceptable decimal places. 

The use of unstructured text fields is discouraged, since their inclusion frequently prohibits straight through 
processing. 

A sub-field within a data item can be: 

— mandatory; 

— conditional: i.e. may or may not be required, or not allowed, depending on the circumstances as defined in the 
Catalogue of Messages; 

— optional: the sub-field should be present when the underlying information exists and is known to the sender. 
However, the message is meaningful without the sub-field. 
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If a data item consists of three optional sub-fields A, B and C respectively, their presence in the data field must be 
indicated by the use of separators. Trailing separators are omitted. 

EXAMPLE 

"x/y/z" means that A, B and C are present, with values x, y and z respectively. 

"x/y" means that A and B, with values x and y respectively, are present, but C is not. 

"x//y" means that A and C are present with values x and y respectively, but B is not. 

"/x/y" means that B and C are present with values x and y respectively, but A is not. 

"x" means that A is present with value x, but B and C are not. 

"/x" means that only B is present with value x. A and C are not. 

"//x" means that only C is present with value x. 

4.3.3 Blocks of data fields 

Blocks of data fields are often used to indicate a repeated or related sequence of data fields within a message. For 
example in a statement of holdings, the information pertaining to each holding may be put in atlock. Similarly a list 
of certificate numbers would be put in a block. 

A block of data fields consists of: 

— a start of block field; 

— a number of data fields and/or blocks of data fields; 

— an end of block field. 

This implies that blocks may be nested within each other. Blocks may be repeated in a message, but not defined 
recursively, i.e. a block may not be defined in terms that include itself. 

If it is required to repeat a data field with the same meaning within a message it should be put in a block. 

4.3.3.1 Start and end of block fields 

The start of a block is indicated by a special discrete data field with the field type ":16R". 

The data item consists of the block name optionally followed, for repetitive blocks, by the occurrence in the 
message and the total number of occurrences in the message. 

The format of this data field is: 

":16R:"16c[T3n[T3n]] 

where the first sub-field {16c) is the block name. Each block apart from repeated occurrences of the same block 
must have a unique block name within the message. 

The optional second sub-field is used for repetitive blocks where it is mandatory. It defines the number of times, 
including this occurrence, that this block has occurred so far in the message. The first occurrence will have a value 
of 1 , the second 2, etc. 

The optional third sub-field defines the total number of times the block occurs in the message. 

For example, the second occurrence of a block of data fields called MYDATA which will occur 3 times would have a 
start of block heading: 

:16BMYDATA/2/3 



11 



IS 15587 (Parti): 2005 
ISO 15022-1 : 1999 

Associated with every Start of Block is an End of Block identified by the field type ":16S". The End of Block discrete 
data field has the format: 

"•.16S:"16c['r3n] 

where the mandatory first sub-field contains the same block name as in the associated start of block data field. 

The optional second sub-field defines, for repetitive blocks, the number of times, including this occurrence, that this 
block has occurred so far in the message. The sub-field is mandatory for repetitive blocks. The value should agree 
with that in the associated start of block data field. 

EXAMPLE 1 (Repetitive block) 

The following repetitive block of amount information contains two data fields. Amount (field type;19a) and Date (field type:98a). 
:16R: AMOUNT/1 
:19A::SETT//USD5000, 
:98A:: VALU//1 997 1020 
:16S:AMOUNT/1 
:16R: AMOUNT/2 
:19A::SETT//USD10000, 
:98A::VALU//1 9971 021 
:16S:AMOUNT/2 

EXAMPLE 2 (Non-repetitive block) 

If the field type for generic data field Number Identification is :13a, a block of certificate numbers could be defined as: 

:16R:CERTIFICATES 

:13B::CERT//7+ 10000+C.234691-7 

:13B::CERT//2+ 1000+A. 1S7232,A. 167111 

: 13B::CERT//1+ 100+D. 123456 

:16S:CERTIFICATES 
End of blocks are specified explicitly. They are not implied. 

4.3.3^ Nesting data blocks 

Data field blocks may contain other data field blocks. A data field block within another data field block must be 
completed within the block. 

EXAMPLE The following example shows how two small blocks may be nested within a larger block. 
:t6R:BIGBL0CK 



:16R:SMALLBLOCK/1 

Data in first small block 

:16S:SMALLBLOCK/1 
:16R:SMALLBLOCK/2 

Data in second small block 

: 16S:SMALLBLOCK/2 



:16S:BIGBL0CK 
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4.3.3.3 Data field block status 



A data field block within a message, like a data field, may have one of the following status in the Catalogue of 
Messages: 

— M mandatory; 

— C conditional: i.e. may or may not be required, or not allowed, depending on the circumstances as 

defined in the Catalogue of Messages; 

— O optional: the data block should be present when the underlying information exists and is known to the 

sender. However, the message is meaningful without the data block. 

The status of a field within a block, only applies if the block exists. 

A block of data fields does not have to include any mandatory fields between the start and end of block fields. 

5 Data Field Dictionary 

The Data Field Dictionary contains information on all registered Enhanced ISO 7775 and EDIFACT fields, as well as 
on the mapping between the Enhanced ISO 7775 data fields and the equivalent information defined in 
ISO/TR 7775, ISITC DSTU 1/1995 or SSAB data dictionaries. 

5.1 Contents 

Each registered field has a unique name and meaning. Only fields that comply with the design criteria are included 
in the Data Field Dictionary. 

The following information is included on each data field: 

— Name of discrete data field (e.g. start of t)lock) or class of generic data field (e.g. date); 

— Definition of the discrete data field or class of generic data fields; 

— Field type; 

— Format of the data; 

— The valid values that the field may take, e.g. a number between 1 and 99 or a list of code words; 

— If the field can take code words, then all the registered code words together with their meaning, usage, and 
status should be given. Code words and code values may be added to a field without giving rise per se to a 
new Data Field Dictionary entry; 

— An example of the use of the field; 

— Rules on how and when to use the data elements in the field. 

— History of the field: 

— when it was created; 

— when it was last updated; 

— whether it replaces another field. 

— List of Registered Message types where the field is used; 

— Where appropriate, a list of all the ISO^R 7775 synonyms, ISITC or SSAB equivalents for the data field; 

— Data Field Dictionary status. 
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Sub-fields in Enhanced ISO 7775 are not registered in their own right, although they are described in the relevant 
field. In the EDIFACT syntax, data elements always need to be registered together with the segment they belong to, 
although the Data Field Dictionary can be accessed by specifying the data element only. 

Similarly, in the Enhanced ISO 7775 syntax, blocks of data fields are not registered, although the start and end of 
block data fields are. The contents of a block are described in the Catalogue of Messages within the registered 
message in which they occur. The start of block data field entry mentions the block names and the messages where 
they are used. 

5.2 Access to the Data Field Dictionary 

The access to the ISO 15022 Data Field Dictionary database is provided to interested parties by means of a paper 
copy, the Internet or agreed substitute network. 

The access to this database will be organized in such a way that it helps the financial institutions in mapping from 
one syntax to another. It will be possible to access the information via "Syntax", from "Messages" or via "Fields" 
directly. 

The Data Field Dictionary will be accessible through Enhanced ISO 7775 and EDIFACT terminology. Reference to 
ISO/TR 7775 synonyms, SSAB or ISITC equivalents are only made in order to facilitate mapping. 

A field registered in the Data Field Dictionary is accessible by either its field tag (Enhanced ISO 7775), by a 
combination of Segment/Data Element (EDIFACT) or by its business name (e.g. date; settlement date). (See 
Figure 1.) 

WEBSITE 



I 

Messages 



1 

Synfax (Enhanced 

ISO 7775, EDIFACT) 



Fields 



Figure 1 — Access to Data Field Dictionary 

5.3 Data Field Dictionary status 

Each field or value will be allocated a status. 
The status may take the values: 

— Live and re-useable; 

— Live but not re-useable; 

— To be removed on a specific date. 

Specific values (e.g. code words) may be specified as going to be removed at a future date, when the field itself is 
marked as live. 

At least 12 months notice will be given prior to removing a field from the Data Field Dictionary. 

Fields in registered live messages may not be removed from the Data Field Dictionary before the message is 
removed from the Catalogue of Messages. 
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5.4 EDIFACT — Enhanced ISO 7775 relationship 



It should be noted that there can be a difference in notation and format between the Enhanced ISO 7775 and the 
EDIFACT standard. Moreover, several EDIFACT segments, (composite) data elements and code words do not 
have an equivalent in Enhanced ISO 7775, e.g. a data segment in EDIFACT could correspond to either a single 
data field or to a block of fields in Enhanced ISO 7775. 

Generally, an Enhanced ISO 7775 data field will correspond to an EDIFACT data element within a data segment. In 
many cases there is a direct one-to-one relationship; in some cases, there is a one-to-many relationship, particularly 
for composite data fields. By way of example, a settlement date in Enhanced ISO 7775 is a single data field 
(:98A::SETT//CCYYMMDD), whereas in EDIFACT this would be represented by separate data elements within the 
DTM (Date Time Period) segment. Similarly, a composite data item in Enhanced ISO 7775 such as in the generic 
data field Amount (-.ISA) which consists of two sub-fields (Currency Code and Amount) would map into two 
separate data elements in the EDIFACT MOA (Monetary Amount) segment. 

Several EDIFACT segments — the Service Segments (e.g. Header and Trailer, Security Segments) as described in 
ISO 9735 — do not have a correspondence in ISO/TR 7775. Since they are not relevant to the Data Field 
Dictionary, they will not be included. 

6 Catalogue of Messages 

The ISO 15022 Catalogue of Messages consists of: 

— Still used ISO/TR 7775 messages, which are registered as version 000 of Enhanced ISO 7775; 

— Enhanced ISO 7775 messages, other than version 000, and their equivalent EDIFACT messages; 

— EDIFACT messages. 

6.1 Contents 

The Catalogue of Messages describes all currently registered versions of all message types. ISO/TR 7775 
messages are attributed version number '000'. The Catalogue of Messages does not include any sub-format 
restrictions imposed by an issuer. 

The message type defines the business scope of the message, e.g. delivery against payment. The version number 
defines the data fields that may be used (and how) to satisfy this business scope in a particular community of users. 

A registered Enhanced ISO 7775 message type and version may only contain data fields and/or ISO/TR 7775 
synonyms of data fields that are registered as re-useable in the Data Field Dictionary. A registered EDIFACT 
message type and version may only contain fields that are registered in the Data Field Dictionary or Service 
Segments as defined in ISO 9735. 

A new version number will only be created if: 

— a new field or fields are required; 

— a field that was mandatory is now conditional or optional; 

— the required conditional structure of fields is incompatible with that in the existing version. 

In particular this means that a new version number will not normally be created in the following circumstances: 

— a different field order is required (Enhanced ISO 7775 only); 

— a field that was conditional is now mandatory; 

— a field that was conditional is now optional; 

— a field that was conditional is now not allowed; 
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— a field that was optional is now mandatory; 

— a field that was optional is now conditional; 

— a field that was optional is now not allowed; 

— only specific code words or formats are allowed for certain fields. 

If an issuer requires a specific sub-format of a message version (i.e. same scope but more specific usage rules), 
then it should use the appropriate version number qualified by a message version sub-format. It is possible for an 
issuer to have more than one sub-format of the same message version, and in the case of a new release, more 
than one version of the same message type, e.g. we could have: 

521 receive against payment message; 

521/004 generic version of receive against payment used by ICSDs; 

521/004/CEDE0041 sub-format defined by Cedel Bank for instructions to receive against payment between 

two Cedel members. 

In the above example, 521/004/CEDE0041 is a message version sub-format of 521/004. This message version sub- 
format is fully compatible with message version 521/004. All sub-formats are valid variations of the message version 
and can thus be pre-validated using the message version validation rules, e.g. any fields which are mandatory in 
521/004 must be mandatory in all sub-formats. 

6.1.1 Message description 

The description of a message in the Catalogue of Messages will consist of the following clauses: 

Description 

Details the purpose and the possible usages of the message, with the sub-headings SCOPE, FUNCTIONS, 
OPERATING PROCEDURES and GUIDELINES. 

The subclause SCOPE specifies the purpose and hence the business scope of the message. It positions the 
message in the entire transaction processing chain, and explains in what situations and between which parties the 
Message is to be used and not to be used. It does not contain usage guidelines, descriptions of sequences, implicit 
field rules, or system constraints. 

The subclause FUNCTIONS summarizes the different functions (e.g. instruction, cancellation, notification, affirmation, 
amendment etc.). 

The subclause OPERATING PROCEDURES explains the business relationships needed to use the Message, such 
as a reference to bilateral/contractual agreements or legal frameworks. It may also define responsibilities of the 
sender arid the receiver. 

The subclause GUIDELINES gives further explanation in a less formal way and without the need for being 
exhaustive. It explains the relationship between the fields representing parties to the transaction, and explains the 
different types of transaction flows and instruction types. It also explains the different scenarios covered by the 
Message and the sequences and fields to be used in what scenario. It may also explain the way the information has 
been grouped into sequences. 

Message format 

Gives the layout of the message in terms of fields and blocks/segments. 

Wherever possible, new messages are listed with fields in the message or within blocks/segments in a logical 
business order. 

The format of fields in the message which are in the Data Field Dictionary is not included with the message in the 
Catalogue of Messages, although restrictions on their use are. In the electronic version, there will be a link to the 
Data Field Dictionary entry. 
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Fields which are not described in the Data Field Dictionary, «.g. ISO/TR 7775 synonyms, are described with the 
message. A reference to the field with which this synonym is associated may be provided in the Catalogue of 
Messages. 

Field usage 

Details any message specific details about the usage of fields, and any conditional rules governing the presence 
and usage of fields in relation to each other, where this is relevant. 

The field descriptions themselves are however not defined in the message but in the Data Field Dictionary. 

An example is normally given for the main scenarios. 

Mapping 

The clause MAPPING explains how to map messages, if applicable. This may refer either to the conversion from an 
old format into a new one, or to the correspondence between two different messages that are part of the same 
information flow. 

6.1 .2 Message status 

Messages and version numbers of messages in the Catalogue of Messages may have the following status. 

— Live; 

— To be removed on a specified date. 

At least 12 months notice will be given by the Registration Authority before a message is removed from the 
Catalogue of Messages. A community of users may notify the Registration Authority during that timeframe that a 
message should be retained. 

6.1 .3 Message version sub-formats 

Although sub-formats of message versions are not part of the Catalogue of Messages, the Registration Authority 
will maintain and publish a list of message version sub-formats. This list will highlight their functions and issuers. 
Details of sub-formats will be available from the issuer. 

6.2 Access to the Catalogue of Messages 

Access to the Catalogue of Messages will be provided to interested parties by means of a paper copy, the Internet 
or an agreed substitute network. 

The Catalogue of Messages will be accessible through the Enhanced ISO 7775 or EDIFACT syntax. 

In the electronic version of the Catalogue of Messages, there will be a link to the Data Field Dictionary. 

6.3 EDIFACT — Enhanced ISO 7775 relationship 

In the Catalogue of Messages, all securities messages and their different versions registered under Enhanced 
ISO 7775 will show tire equivalent EDIFACT securities message(s) and their subsets, which will generally refer to a 
message with a more generic business function registered in the UN/EDIFACT Message Type Directory, if this 
message has already gone through the UN process. 

It should be noted that, as far as message design is concerned, the EDIFACT standard tends towards a broader 
based template approach, whereas the Enhanced ISO 7775 standard enables one to design very specific 
messages. 

Subsets of a message — equivalent to a 'version' in Enhanced ISO 7775 — are not registered in the UN/EDIFACT 
Message Type Directory. However, in the Catalogue of Messages, these subsets will be specifically registered and 
linked to the appropriate version numbers. 
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Annex A 

(informative) 

Message construction guidelines 



Messages in Enhanced ISO 7775 and EDIFACT may be constructed in similar ways. 

Enhanced ISO 7775 message structure 

A message is sent from one party to anotiner; \he message contains a message code which conveys the nature of 
the message. The version of the message is uniquely identified by the message descriptor. The Message consists 
of data fields, which may or may not be grouped into blocks of data fields. Each data field consists of a field type, an 
optional qualifier and a data item. The field type, qualifier or data item are each considered to be data elements; as 
such they may be simple or composite. Composite data elements contain sub-fields. 

Thus a message may be presented hierarchically in the following manner (separators omitted for clarity): 

Message 

Message Descriptor 

Message Code 
Message Version Number 
Message Version Issuer Code 
Message Version Issuer Sub-code 

Block of Data Fields 

Start of Block Field 

Start of Block Field Type 
Start of Block Block Name 
Start of Block Occurrence Count 

Data Field 

Data Field Field Type 
Data Field Qualifier 
Data Source Issuer Code 
Data Source Issuer Sub-code 
Data Field Data Item 

Sub-Field 1 

Sub-Fields n 

End of Block 

End of Block Field 

End of Block Field Type 
End of Block Block Name 
End of Block Occurrence Count 
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ISO 9735 (EDIFACT) message structure 



A message is sent from one party to another; the message contains a header segment which conveys the nature of 
the message. The version of the message is uniquely identified by the message header segment. The Message 
consists of user data segments, which may or may not be grouped as repetitive or nested segments. Each segment 
consists of a segment code data element and one or more additional data elements. Data elements may be simple 
or composite. Composite data elements contain component data elements. 

Thus a message may be presented hierarchically in the following manner (separators omitted for clarity): 

Message Header Segment 

Beginning of Message Segment 
Message Reference Number 
Message Identifier 

Message Type Identifier 

Message Type Version 

Message Type Release Number 

Message Type Controlling Agency 

Repetitive or Nested Segments 

Segment explicitly starting repetition or nesting 
Segment Tag 

Segment Code 

Segment Repetition or Nesting Indicator 

Segment 

Segment Tag 

Segment Code 

Data Element 

Composite Data Element 

Component Data Element 1 

Component Data Element n 
Segment explicitly ending repetition or nesting 
Segment Tag 

Segment Code 

Message Trailer Segment 

Synopsis of Enhanced ISO 7775 and ISO 9735 message structure 

Although the terminology in Enhanced ISO 7775 syntax and in ISO 9735 (EDIFACT syntax) is different, the 
capability and means to hierarchically structure data are similar. Both syntaxes allow for a fixed, small number of 
hierarchical levels to structure data. 
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The following table shows side by side the structural elements of each syntax standard that allow for a similar 
granularity: 



Enhanced ISO 7775 syntax 

Message 

Block of Blocks 

Block of Data Fields 
Data Field 

Sub-field 



ISO 9735 syntax 

Message 

Repetition or Nesting of Segments 
Segment 

Data element 

Component Data Element 



EXAMPLE 1 A block built according to Enhanced ISO 7775 syntax to specify a party in a securities transaction including an 
account sen/iced by this party can be expressed by an EDIFACT Fll (financial institution infonnation) segment, following 
ISO 9735 syntax rules: 



Enhanced ISO 7775 syntax 

Block of Data Fields 



ISO 9735 syntax 

Segment 



EXAMPLE 2 



16R. 
95P. 
97A 
16S. 



SETPRTY 
REAG//DEUTDEFF 
SAFE//1 23456789 

SETPRTY 



FII+REA+123456789+DEUTDEFF:25:5' 



Comments: 

REAG is the qualifier for receiving agent. The party is 
identified by a BIC (Option P). 



REA is the qualifier for receiving agent. 25 is the qualifier to 
specify BIC. 5 is the qualifier to specify ISO as issuer of BICs. 



In the past, dictionaries have been built up according to ISO 7775 and ISO 9735 rules. The rules used to structure 
data have not been the same. Thus when comparing functionally equivalent data, different patterns can be found. 



EXAMPLE 3 For data fields, the Enhanced ISO 7775 generic data field corresponds to a functionally equivalent EDtFACT 
DTM (date/time/period) segment: 



Enhanced ISO 7775 syntax 

Data Field 



ISO 9735 syntax 

Segment 



EXAMPLE 4 
:98A::SETT//1 9970908 



DTI^+205:19970908:102' 



Comments: 

98A is the option to specify CCYYMMDD date fonvat. 
SETT is the qualifier for settlement date. 



205 is the qualifier for settlement date. 

102 is the qualifier to specify CCYYMMDD date fonvat. 



The ISO 15022 Data Field Dictionary and its support for both Enhanced ISO 7775 syntax and ISO 9735 syntax 
through one Registration Authority provides the opportunity for convergence for new fields in the securities industry. 
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The following message construction guidelines only apply to the Enhanced ISO 7775 syntax: 

Message types and version numbers 

Even if a message is intended for private system use, standard message types and version numbers should be 
used wherever appropriate. 

Restrictions and message version sub-formats 

It is possible for a community of users to place restrictions on the acceptable messages, options and formats. 
For example, they may: 

— not accept all the characters in the Latin 1 character set; 

— only accept specific code words; 

— require a field to be mandatory. 

The message type and version number will then be further qualified by a message version sub-fonnat. 
Field order 

The order of fields in a message or block does not change the meaning of the message. Systems should be 
designed to process messages with fields in any order. 

Blocl< structure 

Although theoretically there should be no limit to the number of levels of nested blocks, for practical purposes it is 
recommended that this is limited to 9 levels of nesting, i.e. 8 levels of blocks within the outer one. 

Code words 

Code words should not be mnemonics, as this may be confusing and limit the number of possibilities. 

Optional blocks and fields 

The number of optional blocks and fields in a message should be minimized as they do not facilitate straight through 
processing. 

Default values 

The use of default values is not recommended. It is advocated that an explicit code value is assigned to represent 
the desired default value, e.g. 'NONE'. 
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TECHNICAL CORRIGENDUM 1 



Technical Corrigendum 1 to parts 1 and 2 of International Standard ISO 15022 was prepared by Technical 
Committee ISO/TC 68, Banking, securities and ottter financial services, Sutxiommittee SC 4, Securities and related 
financial instruments. 



This International Standard contains data elements related to dates where the year is formatted in less than four 
digits. The format of these data elements will be considered, and, if appropriate, amended on the occasion of the 
next revision. Meanwhile, it is recommended that users consider, within the context of their implementation of this 
International Standard, any requirements for amendment in relation to the year 2000 and their business 
environment. 
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